儲值備註很適合記下收款說明。但「怎麼收的錢」如果只藏在文字裡，程式每次分類都要重新猜一次：寫現金、轉帳，或只寫某日收款，是否代表同一件事？

便當系統已把這個問題落成一個欄位：topup_method。資料庫結構變更（migration）0009 加入欄位時，刻意讓既有帳務紀錄維持 NULL，並沒有順手從舊備註回填。儲值方式 migration

需要由程式穩定判斷的交易資訊，應從備註升級成結構化資料；新資料要明確，舊資料不知道的部分仍然可以不知道。

儲值方式和備註回答不同問題

這次欄位只處理管理者替成員儲值時記錄的收款方式。可用值有台灣 Pay、LINE Pay MONEY、帳戶轉帳、現金與 iPASS MONEY；備註仍另外保留。

它不是所有交易調整原因的通用分類，也不表示系統串接了這些支付業者，更不代表外部款項已由 API 自動確認入帳。這個界線若沒說清楚，一個收款方式欄位就可能被誤讀成完整付款整合。

後端 requireTopupMethod 要求新儲值帶入合法值：缺值回 TOP_UP_METHOD_REQUIRED，未知值回 TOP_UP_METHOD_INVALID，沒有「缺了就當現金」的預設。後端驗證

這讓「新交易填完整」成為寫入前的條件，而不是靠事後整理備註補救。

欄位要跟著交易走，不只出現在選單

topUpBalance 把儲值方式放進三個地方：儲值寫入路徑

• 重試請求的內容識別：requestHash 包含目標、金額、方式與備註。
• 稽核紀錄：BALANCE_TOP_UP 同時留下方式、金額、備註及交易識別。
• 帳務寫入：ledger 保存 topupMethod，備註仍是另一個欄位。

第一點尤其容易漏掉。如果金額相同、方式不同，卻被重試機制當成完全同一份內容，新的欄位就只剩裝飾。把它放進請求識別，才能讓重試檢查知道交易內容是否改變。

這裡沿用既有交易與重試機制，不重新設計帳務架構；新增責任是讓方式欄位一路保留到可追查的紀錄。

新畫面的預設值，不能變成舊資料的答案

在本文核對的來源版本（eaf76fa3）中，v0.15.6 起新增儲值會預設台灣 Pay，備註預填台北當日的「M/D收款」，仍可修改。這是減少新輸入操作的介面選擇。前端設定

另於 2026-10-03 擷取的未送出表單，來自介面顯示 v0.15.4 的部署：方式仍未選，備註是「現金收款」。這張圖能說明方式與備註已分欄，不能用來證明較新來源版本的預設值。

新增表單的預設值不能推出「舊資料沒有方式時，也當成台灣 Pay」。migration 對歷史列保留 NULL，後端對新請求拒絕缺值，兩件事並不矛盾：前者承認過去沒記錄，後者要求從這次開始記錄。

顯示交易明細時也有相同分界。formatTransactionDescription 只在儲值交易具有已知方式時組合「方式｜備註」；舊資料沒有方式，就沿用原 description 或 note，不解析自由文字去猜。交易說明格式

Day 24 談過歷史證據的更新邊界。這個欄位把邊界落成不同的讀寫規則：新寫入要求明確，舊讀取保持相容。

什麼叫做這個欄位真的接完整

Repo 的測試定義不只檢查選單存在，也涵蓋合法方式保存、缺值或錯值時不新增儲值、不改餘額，以及舊 NULL 的顯示退回路徑。後端測試、前端測試

本次核對的是 schema、程式與測試定義，沒有執行正式儲值、查詢正式帳務或重跑測試。這些來源足以說明欄位的契約，不能當成某筆真實收款已確認的證據。

讓 AI 幫忙分類，也要保留未知

AI 可以協助掃描舊備註、列出候選對應和無法判斷的案例。但這是可以採用的後續調查方式，本篇沒有證據顯示已完成過這樣的批次回填。

要把候選值寫回歷史，仍需要逐筆可追溯來源與另外核准的修改範圍。模型說「很像轉帳」並不會增加當年的收款證據。

這次建模值得帶走的判斷很小：當欄位開始影響驗證、重試、查詢或稽核，就讓它有固定值與明確規則；文字繼續保存人需要的說明。AI 能快速把選單接好，工程上要補齊的是新寫入、交易識別與舊資料相容這整條路。

本系列實作專案

這是一套持續開發中的便當訂購系統。文章著重「為什麼」，GitHub 保留實際程式碼、文件與演進紀錄。

GitHub：https://github.com/henryfir456/bento-order-app

下一篇會把這個小欄位放回整套系統：功能越來越多之後，要用什麼證據判斷它們仍然能一起運作？